Welcome back.
In this lecture we're going to be taking a look at something called the unreliable remote event instance.
Unreliable remote.
This must be a joke right.
Why would we ever want a remote to be unreliable?
Well, there's actually good reason for having an instance like this inside of the Roblox API.
And before we discuss that, we need to first understand how remote events send data to the server and
how that compares with the unreliable remote event when remote events send information to the server,
if the data is large enough, it will be split up into these things called packets.
And those packets are directed towards a specific destination.
And when they reach their destination, they're stitched back together again to get the full set of
data.
However, sometimes due to problems out of our control, these packets can become what's known as lost
meaning.
The recipient of these packets never received them, so regular remote events will keep resending those
packets until it has confirmed that the recipient received the packets.
The problem with this is that it can clog the pipe of data trying to be sent through a remote event,
as the remote event will prioritize making sure a packet reaches its recipient before sending another
set of data.
This can lead to network latency and poor user experience in your games.
Now, this is mostly true if you're firing remote events rapidly.
If you need to fire a remote event rapidly and you care more about improved network latency over packet
loss, then that's what we use unreliable remote events for.
As an example, think of the TCP and UDP internet protocols.
The purpose of TCP is to send data in an orderly fashion, and it ensures that data reaches its destination.
This makes it transfer data slower, but it's extremely reliable.
UDP, on the other hand, is not reliable like TCP, as it does not check to make sure that a packet
reaches its destination.
The main goal of UDP is to get data out as fast as possible.
So while UDP is less reliable, it is much faster than TCP.
This same idea can be thought of with remote events and unreliable remote events.
Remote events are reliable, ordered and send data slower and unreliable.
Remote events send data very quickly and unordered, and they aren't concerned about packet loss.
Now that we have a good idea of what the purpose of the new unreliable remote event is for, you may
be wondering when would I ever use it?
Well, there are many cases you may want to use an unreliable remote event as an example for replicating
effects across the client server boundary, or sending data to the server rapidly and quickly to update
something that all clients need to see.
Let's say you had a fire extinguisher tool, and you would like to be able to control the direction
of particles coming out of the fire extinguisher based on the position of the mouse on a player screen.
Well, in order for the server to be able to know where the mouse is on a player's screen, the player
has to send that data to the server.
Depending on how fast you want the particle direction to update.
If you tried to fire the position of the mouse rapidly using a regular remote event, you'll probably
run into some network congestion.
But if you use an unreliable remote event, you can fire it rapidly.
And you don't have to worry about network congestion because if the packet is lost, it's fine because
the next packet will probably make it to the destination.
Another example could be with a vehicle system.
It's commonly stated that you should try to have the client do as much heavy lifting as possible, and
have the server do the least.
That way your game does not become laggy with a vehicle system.
Let's say the playback speed of the sound for the engine needs to be updated depending on the speed
of the vehicle.
If you had the server checked this and you had many players in your game with lots of vehicles, you
could end up running into performance issues on the server.
What would be the fix for this?
Have the speed checks be done on the client, and have the client send information to the server via
an unreliable remote event to tell the server how fast the engine sounds playback should be.
There are many more uses for unreliable remote events, but those were just a couple to demonstrate
the use of an unreliable remote event.
Let's go ahead and create a tool where the client can control the direction of particles coming out
of it.
So let's go ahead and create a new tool inside of the starter pack.
I'm not going to name it anything because this is just a demonstration tool.
And then let's go ahead and create a part in here.
This is going to be my handle.
So we'll name it to handle.
And then I'm going to make sure I disable Can Collide.
And then inside of this handle I'm going to add an attachment.
And this is where my particle emitter is going to be.
And what we're going to do is we're going to have the particle emitter emit from the front of our attachment.
So we'll set it to front.
And then we're going to update the keyframe of this attachment to be looking towards wherever our player's
mouse is.
So that way the particle emitters are emitting in the direction of the player's mouse.
I'll also decrease the size of the handle.
I'll just make it 0.5 by 0.5 by 0.5 studs.
And then let's go ahead and create a server script.
Than here.
We're going to need a local script as well.
And then we're going to create an unreliable remote event.
And I'm going to name this update inside of my local script.
Let's go ahead and get the player service so we can grab the local player, because we're going to need
the player's mouse object.
And then we're also going to grab the run service because I want to fire to the server every single
heartbeat.
So let's go ahead and get the player which is player is that local player.
We'll get the mouse, get mouse.
And then we'll also go ahead and make a reference to the tool which is script dot parent.
And then when the tool is equipped what we want to do is we want to start listening to the run service
heartbeat event.
And then when the tool is unequipped, we stop listening to the heartbeat event.
So let's go ahead and listen to both the equipped and unequipped event.
And then up here we're going to listen to Run Service Heartbeat.
And we're going to connect a function to it.
And all this is going to do is we're going to refer to our unreliable remote event.
And this has the exact same functions as a regular remote event.
So we can fire to the server some information.
And that information is going to be the position of our mouse in the workspace.
So we can refer to mouse dot hit and get the position.
And that's all the server is going to need.
And then when we unequip our tool we want to make sure we disconnect this function from our heartbeat
event.
So let's go ahead and store a connection in a variable.
Let's declare it up here.
Call it connection.
And then connection is going to be equal to that.
And then when we unequip it we can check if we have a connection.
And if we do we'll make sure to disconnect that and set it equal to nil.
And then we can do the exact same thing up here just in case.
Now inside of the server script let's go ahead and make a reference to our tool.
So script dot parent.
And then we're just going to listen to our unreliable remote event.
And we're going to get the on server event.
So just like a regular remote event we'll connect.
We'll get that player that fired the event.
And then hopefully we'll also get past a mouse position.
And now what we can go ahead and do is we can calculate what the keyframe should be for our attachment.
And we're going to use keyframe dot look at.
And we're going to be using the position of the attachment in our handle looking towards the position
of our mouse.
So let's refer to tool dot handle dot attachment.
And then we're going to get world position.
And we're going to have it look towards our mouse position.
Then we can go ahead and set the handle dot attachment.
We want to update its world keyframe equal to the keyframe that we just calculated.
So we'll store that in a variable.
We'll call it Look Keyframe.
And then that's what we'll update the attachment to.
So now every single heartbeat on the client, we're going to be firing to the server to update the position
or I mean the rotation of our attachment.
So that way all the particles coming out of the attachment is going to be following the position of
our mouse.
So let's go ahead and try it out.
If we play test our game here's our tool if I equip it.
There's our particles coming out.
And if you notice, look at that.
It's going towards the direction of our mouse.
If I move my mouse over here now, the particles are moving towards again the direction of my mouse.
And now I have total control over the direction of particles coming out of my tool, which is very cool.
I can point it up in the sky and the particles will move in that direction.
I can point it over here and over here.
Look at that.
And since all we're sending to the server is the position of my mouse to update the keyframe of the
attachment, it doesn't really matter if we lose a couple of packets here and there, because it's not
a crucial game mechanic.
If you have any crucial game mechanics where you need information from the client to reach the server,
then yeah, use a regular remote event.
But for situations like this where all you need to do is like update a particular thing or some visual
effect.
Yeah, use unreliable remote events.
That's all from me in this lecture.
I hope you enjoyed and I'll see you in the next one.